1. Technical Field of the Invention
This invention relates to computer software systems and, more particularly, to a self-configurable distributed system and a method of enabling software application programs running on one machine to obtain needed adapter functionality from another machine.
2. Description of Related Art
The World Wide Web (the xe2x80x9cWebxe2x80x9d) is rapidly growing in popularity, and as it does, so does the use of Web browsers. Portions of client software application programs known as xe2x80x9cappletsxe2x80x9d run inside Web browsers. Many times, the applets required to perform a complete function are distributed throughout the Web on different machines. In such distributed systems, a new component category can appear and be removed on-the-fly; when this happens, older components must learn how to communicate with these new components through a self-configuration mechanism, for example automatically loading appropriate display handlers or content handlers. Self-configuration, therefore, is increasingly becoming a required feature because of the dynamic nature of distributed systems.
Web server machines are basically repositories of Hyper-Text Machine Language (HTML) pages for general browsing and Java classes for applets. This mixture of HTML pages and Java classes raises security issues regarding the applets, so an applet security model, also referred to as the xe2x80x9csandboxxe2x80x9d, has been created. Due to constraints imposed by the applet security model, applets can only open a connection to the machine that they have been downloaded from, which is their own Web server. This constraint is a serious limitation when applets themselves are components of a distributed self-configurable system because each applet can only communicate with components located on the same machine that is hosting the original server the applet was downloaded from. Additionally, the applets can only load configuration classes such as display handlers or content handlers from that particular Web server, and nowhere else. Because of the dynamic nature of distributed systems, applets that are themselves components of a distributed system are too limited by the sandbox.
When utilizing Common Object Request Broker Architecture (CORBA) mechanisms, part of this problem is resolved through the use of gatekeeper technology. The gatekeepers act as intermediaries on the Web server machine, and use a tunneling mechanism to open connections to other machines. A CORBA-based applet can open a xe2x80x9cvirtualxe2x80x9d connection to CORBA objects that are located on other machines. This elegantly solves the problem of enabling applets to open connections to any CORBA objects.
The gatekeeper technology, however, solves only half of the whole problem. Applets can open connections to any CORBA objects even if they are not located on the Web server machine, but the solution does not work if further self-configuration is required before the communication can take place. For example, if an applet wants to communicate with a CORBA object on Machine-Z (which is not the Web server), but requires a special content handler that is also stored on Machine-Z in order to do that, there is currently no way that the content handler can be downloaded from Machine-Z. This is because (1) the applet cannot open a direct connection to Machine-Z, and (2) even if the connection could be indirectly opened using a mix of CORBA and gatekeeper technology, the downloaded byte code could not be converted into a fully instantiated Java class because applets are not allowed by the sandbox to create class loaders. A class loader is the only way to convert byte code into a Java class.
An alternative approach may be to copy Java classes on the web server""s machine. However, this approach is highly impractical and extremely difficult to manage. If new component types requiring new display handlers are introduced on the fly, it would require a cumbersome mechanism to make sure their display handler classes are copied on the web server machine.
Another alternative is using signed applets. The use of signed applets, however, is very complex, and the code must be signed with security keys, and certificates are required. Therefore, the use of signed applets is not practical for real-time self-configuration in a distributed system.
In order to overcome the disadvantage of existing solutions, it would be advantageous to have a system and method for enabling applets to get adapter functionality from other machines. The present invention provides such a system and method.
The present invention is a self-configurable system that includes a Web browser hosting applets and providing them with an execution environment, a Web server to which the Web browser is issuing requests, a servlet at the service of the Web server, and finally a distributed persistent storage mechanism to which the servlet is issuing queries on behalf of the Web server. Many other Web servers may share the storage mechanism which holds among other information, Java byte code for adapters that are used by a plurality of applets and possibly other distributed applications.
A typical applet running in the execution environment of the Web browser might require at some point in its life to load a new Java class in order to continue its normal operation. If the class is not available from the browser""s execution environment, the browser automatically attempts to fetch the needed Java class from the Web server where the applet originated. The Web server, in turn, attempts to load the byte code for the class from its local disk. If this attempt fails, a new servlet attempts to retrieve the code from the distributed persistent storage mechanism, which is likely to be on a different machine than the Web server. The servlet then provides the Web server with the retrieved byte code, and the server sends the code to the browser. The browser includes an integrated class loader which then converts the byte code stream into a Java class directly usable by the applet. In this way, the applet is able to successfully load a Java class from a location that is different than the applet""s originating Web server.
Thus, in one aspect, the present invention is a self-configurable distributed computer software system that includes a Web browser, a distributed persistent storage mechanism that stores byte code utilized by a plurality of applets distributed throughout the system, and a Web server connected to the Web browser and to the distributed persistent storage mechanism. An applet runs on the Web browser and requires byte code stored outside the Web browser in the persistent storage mechanism. The Web server includes a local storage disk for storing byte code, a servlet for retrieving the byte code from the persistent storage mechanism if byte code requested by the Web browser is not stored on the local storage disk, and communication means for sending the retrieved byte code to the Web browser. The code may be stored as Java classes, and the persistent storage mechanism may be a Lightweight Directory Access Protocol (LDAP) server.
In another aspect, the present invention is a method of enabling an applet running on a first machine to obtain needed software code from a second machine that is distinct from the machine hosting the applet""s originating Web server. The method includes the steps of sending a request for the software code from the first machine to a server having a local storage disk, determining in the server whether the requested software code is stored on the local storage disk, and sending a request for the software code from the server to a distributed persistent storage mechanism upon determining that the requested software code is not stored on the local storage disk. This is followed by sending the requested software code from the persistent storage mechanism to the server, and sending the requested software code from the server to the first machine.